Say only the audit events this deployment can actually record - #540

What this changes

Four event types are declared in auditEventTypes and written by nothing in server/src:

They stayed for months because the taxonomy test named them explicitly, so the list kept agreeing with itself rather than with the code.

This removes them, and adds the guard that would have caught it.

Where it runs

server/src/audit.ts — the declaration only. No writer changes, because there are none to change.

Boundary and audit

This is the audit trail, so the reason is the operator's, not the type checker's.

The Audit screen filters by event type. Filtering for knowledge.searched returns an empty page, and an empty page in an audit trail reads as this did not happen rather than this cannot happen. Those are very different answers to give someone checking whether a search touched a document, and the record currently cannot distinguish them. A trail that can say nothing is worse than one that says nothing, because the reader cannot tell which they are looking at.

Reading old rows is unaffected, and I checked rather than assumed:

• The Audit UI does not enumerate auditEventTypes. It uses the curated REFUSED_EVENT_TYPES and DID_NOT_HAPPEN_EVENT_TYPES groups, and neither names any of the four.
• AuditEvent.eventType is a plain string, not the union, so a historical row carrying one of these still loads and renders.

So this narrows what the type is allowed to claim, not what the table is allowed to hold — which is the right direction for a record you are not allowed to rewrite.

Changelog

Not user-facing — no operator can currently see these types produce anything, which is the bug.

Proof

The new test, declares nothing this deployment cannot write, reads the event types off server/src rather than off a hand-kept list, because a hand-kept list is exactly what just failed. Run against main and against this branch:

--- main ---
declared: 70
unwritable: [ "connector.sync_succeeded", "connector.sync_failed",
  "knowledge.searched", "agent.invoked" ]

--- this branch ---
declared: 66
unwritable: []

It fails on the bug and passes on the fix, which is the only property a guard has to have.

It matches literal strings only. That is deliberate: every writer today passes the type as a literal, and a writer that computed one would fail here and should — an event type a reader cannot grep for is worse than this test being strict.

I could not run bun test server/tests/audit.test.ts end to end on this machine. The file imports createApp, and my node_modules is stale — cron-parser, @ag-ui/mastra and @mastra/client-js are declared in package.json but absent locally, so the import fails before any test runs. I confirmed this failure is identical on unmodified main, and ran the guard's logic standalone against both trees to produce the numbers above. bunx tsc --noEmit in server/ reports only those same three missing packages and nothing from these files.

What is not covered

• The reverse direction — a type written in server/src but missing from the taxonomy — is not checked here. It is a real gap, but catching it means recognising writer call sites rather than grepping strings, and that is its own change.
• I have not tried to restore the connector or knowledge features. If either comes back, its author re-adds the type in the same commit as the writer, which is the order this guard now enforces.

🤖 Generated with Claude Code